On a computer network like the Internet, services such as a social networking system (SNS) and a blog (a weblog) are popular.
In these services, each user using the service has a uniquely assigned ID (identifier) (i.e., an ID for identifying the user). Moreover, server devices providing these services each store profile information representing attributes (name, date of birth, preference, and so on) of each user in association with an ID assigned to the user.
In a case that each of the plurality of services issues an ID to a user independently from each other, different IDs depending on the respective services are assigned to a single user. In this case, there is a problem that a user using the plurality of services needs to use the plurality of IDs, respectively, and therefore it is less convenient. Moreover, there is a problem that other users cannot judge whether a user to whom a first ID is assigned in a first service is identical to a user to whom a second ID is assigned in a second service (i.e., cannot judge the identity of the users).
A technique to assign a common ID to a plurality of services (across a plurality of services) to a single user is called Single Sign On. As one of the techniques to realize Single Sign On, a distributed ID federation system is known. An example of this technique is OpenID described in Non-Patent Document 1.
FIG. 1 shows the outline of a procedure for confirming a user ID in OpenID. This procedure is described in “3. Protocol Overview” of Non-Patent Document 1.
Single Sign On in OpenID is configured by a user terminal (referred to as a User-agent in OpenID) operated by a user, a service provider (referred to as a Relying Party (RP) in OpenID), and an ID Provider (referred to as an OpenID provider (OP) in OpenID).
In OpenID, the following processes of steps 1 to 7 are executed.
Step 1: A user terminal is connected to an RP, and presents an ID called a user-supplied identifier to the RP. Typically, a user-supplied identifier includes a URL (Uniform Resource Locator) for specifying an OP having issued the user-supplied identifier.
Step 2: The RP specifies the URL of the OP based on the user-supplied identifier presented at step 1.
Step 3: The OP and the RP exchange a common key used for electronic signature with each other.
Step 4: The connection destination of the user terminal is switched (e.g., redirected) from the RP to the OP. At this moment, an OpenID authentication request issued by the RP is transmitted to the OP via the user terminal.
Step 5: Through the user terminal, an authentication process is executed between the user and the OP. An authenticating means is not included in the specification of OpenID. Typically, the authentication process is a process of confirming whether a combination of an ID (claimed identifier) and a password presented by the user matches a combination of an ID and a password previously registered into the OP. In response to the OpenID authentication request, the OP transmits information in which an electronic signature generated by using the common key exchanged at step 3 is added to information (assertion) representing success of authentication, to the user terminal.
Step 6: The connection destination of the user terminal is switched from the OP to the RP again. At this moment, the user terminal transmits a combination of the assertion issued at step 5 and the electronic signature to the RP.
Step 7: The user terminal transmits the encrypted assertion accepted at step 5 to the RP. The RP verifies the result of the authentication by decoding the electronic signature by using the common key exchanged at step 3.
Thus, by using the technique of Single Sign On such as OpenID, a user can utilize a plurality of services by using the same ID.
However, in a case that a common ID to a plurality of services is used, the attributes of a user (i.e., personal information) and privacy information like the history of usage of the services that are possessed by the providers of the respective services can be related among the services. Therefore, there is a fear that personal information and privacy information are disseminated beyond the intent of the user.
In order to solve this kind of problem in the case of using OpenID, there is a known operation method of registering a single user ID (a common ID; referred to as OP-Local Identifier in OpenID) and a password into the OP and issuing a different user ID (an individual ID; Claimed Identifier) depending on each service.
Further, as another technique for realizing Single Sign On, an access authority delegation system is known. One example of this technique is OAuth described in Non-Patent Document 2.
OAuth is a protocol for, by using the authority of a user on a certain service (a service provider), accessing information (resource) possessed by the service provider from another service (a consumer). At this moment, the user does not need to disclose either the user ID or the password directly to the consumer, so that Single Sign On is realized.
FIG. 2 shows the outline of an operation procedure of OAuth.
In prior to the following operation procedure, a consumer possesses a combination of an ID called a consumer key and a password called a consumer secret issued by a service provider.
Step 1: A user performs a predetermined operation to the consumer. This step is outside the range of the OAuth protocol. Typically, this operation is an operation that the user instructs to associate user information registered to the service provider with the consumer.
Step 2: The consumer requests the service provider to issue a request token (transmits a request token acquisition request). A request token is an identifier for identifying a request token acquisition request. The request token acquisition request includes a signature issued by using the consumer key and the consumer secret. In response to the request token acquisition request, the service provider transmits a request token to the consumer.
Step 3: The user performs an operation of authorization (permission) with respect to the request token for the service provider.
Step 4: The consumer requests the service provider to issue an access token corresponding to the request token. An access token is a temporary identifier which is necessary when the consumer accesses the service provider. In a case that the user has succeeded in authorization at step 3, the service provider transmits the access token to the consumer.
Step 5: The consumer accesses the resource possessed by the service provider (acquires the information) by using the access token acquired at step 4.
In the case of using OAuth, it is possible to judge the identity of a user across a plurality of services. This is because a consumer can refer to a user ID on a service provider by using delegated user authority, and therefore, it is possible to judge whether a specific user ID on the consumer and the user ID on the service provider are assigned to the same user.    [Non-Patent Document 1] “OpenID Authentication 2.0—Final,” OpenID Foundation, Dec. 5, 2007, Section 3    [Non-Patent Document 2] “OAuth Core 1.0 Revision—a,” OAuth Core Workgroup, Jun. 24, 2009, Section 6
As described above, in a case that different user IDs (individual IDs) depending on the respective services are used in OpenID, there is a problem that other users cannot judge whether a user to whom a first individual ID is assigned in a first service is identical to a user to whom a second individual ID is assigned in a second service (i.e., cannot judge the identity of the users).
Further, in OAuth, there is a problem that, in order to prevent the abuse of the authority of a user by an external service, there is a need to previously transmit a consumer key and a consumer secret issued by a service provider to a consumer.
That is to say, in the abovementioned techniques, there is a problem that it is impossible to cause other users to judge the identity of a user to whom a different ID depending on each of a plurality of services is assigned, without previously performing a process of causing a service provider to issue a consumer key and a consumer secret and also transmitting them to a consumer.